The present invention relates generally to client/server messaging systems and more, particularly to the responsibilities of clients in such messaging systems.
Asynchronous transfer of messages between application programs running on different data processing systems within a network is well known in the art, and is implemented by a number of commercially available messaging systems. These systems include IBM® WebSphere® MQ family of messaging products, which use asynchronous messaging via queues (IBM and WebSphere are registered trademarks of IBM Corporation within the United States, other countries or both). A sender application program issues a command to send (put) a message to a target queue, and a Websphere MQ queue manager handles the complexities of transferring the message from the sender to the target queue, which may be remotely located across a heterogeneous computer network. The target queue is a local input queue for another application program, which retrieves (gets) the message from this input queue by issuing a command asynchronously from the send operation. The receiver application program then performs it processing on the message, and may generate further messages.
Messaging products such as Websphere MQ provide for assured once and once-only delivery of persistent messages even in the event of system or communications failures. This is achieved by not finally deleting a message from storage on a sender system until it is confirmed as safely stored by a receiver system, and by the use of sophisticated recovery facilities.
Publish/subscribe (pub/sub) data processing systems have become popular in recent years as a way of distributing data messages. Publishers are typically not concerned with the mechanics of the message distribution, and client subscribers are typically not interested in where the messages they receive have come from. Instead, a message broker typically assures the integrity of the message source, and manages the distribution of the message according to the valid subscriptions registered in the broker.
Publishers and clients may also interact with a network of brokers, each one of which propagates subscriptions and forwards publications to other brokers within the network.
One such pub/sub broker is the IBM WebSphere Business Integration Message Broker. In operation the broker connects to a number of publishers each of which publishes messages to the broker on particular topics (e.g. news, weather, sport). Subscribers connected to the broker register their interest in such topics via subscription requests sent to the broker. The subscribers may be systems that are semi-permanently connected to the broker (e.g. via the Internet) or may be devices that connect less frequently to retrieve messages. Examples of the latter type of the device include PDAs (which may connect using IBM WebSphere Everyplace) or mobile phones. For example, one subscriber may request to receive any information published on the weather, whilst another subscriber may desire information on news and sport.
When the broker receives a message on a particular topic from a publisher, the broker determines from its list of subscriptions to whom that message should be sent; and places the message on a queue associated with each listed client subscriber. The messages are kept by the broker until such time as the subscriber connects to the broker. The messages are then transmitted to the subscriber.
The storage provided by the broker for the message queues will have finite capacity and therefore the broker relies on the subscribers to regularly connect to the broker to receive messages. Subscribers that are delinquent in allowing a build up of messages at the broker can cause a degradation in broker performance for well behaved subscribers. It would be desirable to provide a messaging system that addresses the problem of delinquent client systems.